Click Here!
home account info subscribe login search My ITKnowledge FAQ/help site map contact us


 
Brief Full
 Advanced
      Search
 Search Tips
To access the contents, click the chapter and section titles.

Oracle Performance Tuning and Optimization
(Publisher: Macmillan Computer Publishing)
Author(s): Edward Whalen
ISBN: 067230886x
Publication Date: 04/01/96

Bookmark It

Search this book:
 
Previous Table of Contents Next


Physical Data Layout

This section looks at how the data in a BLOB system should be configured on the physical disks. First, it looks at how to lay out the data on traditional disks; then it looks at disk arrays. I recommend using disk arrays if at all possible; the ease of use and performance benefits are worth the cost of the array.

The main goal in designing the physical data layout is to balance the I/O across all the disks that are randomly accessed and to isolate the sequential I/O. Depending on your application and how often you insert new data into the system (or whether you use the system simply for data retrieval), the redo logs may or may not be significant.

If data is updated or inserted on a regular basis, the redo log files should be separated. If little or no update/insert activity occurs, you can use a minimal redo log configuration. In a BLOB system, you know that the majority (if not all) of the data files are accessed in a random fashion but may take advantage of multiblock reads. The individual object requests are done with sequential requests, but because many data streams will be active, the sequential access is randomized.

In other chapters, I recommended that more, smaller disk drives are more advantageous than a few larger disk drives. For system that access BLOBs, I make an exception. It is still important to take advantage of as many disks as possible, but if a 4.3 gigabyte disk has a significantly faster data access time than a 2.1 gigabyte disk, I recommend the faster disk. I reverse my usual recommendation because much of the data access is done using sequential I/O of the size of the multiblock read.

Traditional Disks

The layout for a system used for BLOB data is somewhat more complicated than most configurations. A minimal configuration should look something like this:


Element (# of Disks) Comments

System (1+) The system disk is used for the operating system, swap file (if applicable), user files, and Oracle binaries.
Redo log (0) Little or no insert/update activity. Because very little update activity is involved with this system, the log files are not active and are not a bottleneck. The disk drives normally allocated as redo log drives can be better used for data files. The redo log files can reside on the same disk as the system.
Redo log (2+) Some insert/update activity. If online updates are done to the system, you must separate the redo log files for both protection and performance. Whether you need to add separate redo log drives or not depends on the extent of the updates.
Archive logs (0) Little or no insert/update activity. As with the redo log files, archiving is minimal and not necessary when there is little update activity. The archive log files can also reside on the system disk.
Archive logs (1+) Some insert/update activity. As with the redo log files, if updates are done on this system, you must provide for the sequential nature of the archive log files.
Data files (1+) The number of disks you need for data is determined by the amount of random I/O the requests for data generates and the size of the database.
Index files (0) This type of system typically uses very small indexes because the large amount of data in the system is usually made up of a small number of very large records. No separate index disk drives are needed; these indexes can reside on the same disk drives as the data.

The data files should be striped over as many disk drives as necessary to achieve optimal I/O rates on those disks. From Chapter 14, “Advanced Disk I/O Concepts,” remember that you can only push a disk drive to a maximum random I/O rate.

As you have seen in previous chapters, the data can be striped across the disks using Oracle or RAID striping or a combination of the two. Because the disk array provides excellent performance and is easy to use, when you use a disk array, the task of distributing I/Os can be greatly simplified.

Disk Arrays

For a system that accesses BLOBs, the layout using a disk array is much simpler than it is with traditional disk drives. A minimal configuration should look something like this:


Element (# of Volumes) Comments

System (1+) The system disk is used for the operating system, swap file (if applicable), user files, and Oracle binaries. If possible, you should mirror this disk for additional fault tolerance.
Redo log (0) Little or no insert/update activity. Because there is very little update activity involved with this system, the log files are not active and are not a bottleneck. The disk drives normally allocated for the redo log volumes can be better used for data files. The redo log files can reside on the same disk as the system.
Redo log (1+) Some insert/update activity. If online updates are done to the system, you must separate the redo log files for both protection and performance. Whether you need to allocate an additional logical volume for redo log files depends on the extent of the updates. This volume should be made up of at least two physical disks using RAID-1. By using only one log volume, performance degrades during archiving because the sequential nature of the log writes is disrupted.
Archive logs (0) Little or no insert/update activity. As with the redo log files, archiving is minimal and not necessary when there is little update activity. The archive log files can also reside on the system disk.
Archive logs (1) Some insert/update activity. The number of disks needed for the archive log files is determined by the amount of data you have to archive. This data can be written to tape as necessary.
Data and index (1+) Because you always get concurrent access to disks with a disk array, it is not necessary to split the data and indexes into separate volumes. The number of disks you need for data and index is determined by the amount of random I/O the requests for data generates and the size of the database.


Previous Table of Contents Next


Products |  Contact Us |  About Us |  Privacy  |  Ad Info  |  Home

Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc.
All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited.